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REMARKS/ARGUMENTS 

Applicants submit herewith an IDS. Applicants request review and consideration of the 
references listed in the submitted IDS. 

Applicants amended claims 10, 26, and 42 to clarify the antecedent basis of 
"authentication information". 

Applicants amended claim 20 to change the dependency to claim 19. 

1. Claims 1-10, 13, 15, 17-26, 29, 31. 33-42, 45, and 47 are Patentable Over the Cited Art 

Claims 1-10, 13, 15, 17-26, 29, 31, 33-42, 45, and 47 have been rejected under 35 U.S.C. 
103(a) as being unpatentable over Putzolu (U.S. Pat. No. 6,681,243) in view of Flores (U.S. No. 
5,630,069). This rejection is respectfully traversed. 

Independent claims 1,17, and 33 concern enabling access to a plurality of service 
engines, wherein each service engine enables access to service resources, and require: providing 
a plurality of service class implementations for service engines from different vendors, wherein 
each service class implementation provides an implementation of methods and objects from a 
same abstract service class; instantiating a service object for one service engine in response to at 
least one called method from one of the service class implementations, wherein the service 
object includes information on the service engine; receiving a method call from one service class 
implementation requesting information on service engine resources for one named service; and 
using the service object to access the requested information to return to the method call. 

The Examiner cited col. 5, lines 55-59, col. 6, lines 62-65, col. 14, lines 42-67 and col. 
15, lines 1-67 of Flores as teaching the claim requirement of providing a plurality of service class 
implementations for service engines from different vendors, wherein each service class 
implementation provides an implementation of methods and objects from a same abstract service 
class. (Final Office Action, pg. 3) Applicants traverse. 

The cited col. 5 mentions a network of workflows linked together that represent recurrent 
process by which an organization performs and completes work, delivers products and services 
and satisfies consumers. There is no mention or suggestion in the cited col. 5 of the claimed 
service class implementations of a service engine, enabling access to service resources, from 
different vendors, where each implementation is of a same abstract service class. There is no 
mention in the cited col. 5 of "linked workflows" that these workflows are from different 
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vendors providing implementations of abstract service classes to enable access to their service 
engines. 

The cited col. 6 states that a workflow is a structured set of acts between customers and 
performs organized to satisfy a customer's condition of satisfaction. There is no mention or 
suggestion in the cited col. 6 of service class implementations of a service engine, enabling 
access to service resources, from different vendors, where each implementation is of a same 
abstract service class. Nor is there any teaching in the cited col. 6 of different vendors providing 
an implementation of a same abstract service class to access the vendor service engine as 
claimed. 

The cited col. 14 discusses a Model- View-Controller (MCV) framework that provides a 
split of the different functions in a GUI application. Isolating the core application logic in the 
model makes the application more portable and the implementation extendible. The logical 
separation of the event handling in the Controller from the user interface in the View enables the 
application to be more easily ported to another GUI environment. The Model classes describe 
the business process and components in terms o a hierarchy of classes, the View classes draw the 
workflow map of the business process on different displays. 

Although the cited col. 14 discusses logical separation of a GUI application, nowhere 
does the cited col. 14 teach or suggest providing service class implementations of a same abstract 
service class from different vendors as claimed. There is no mention or suggestion in the cited 
col. 14 of service class implementations of a service engine, enabling access to service resources, 
from different vendors, where each implementation is of a same abstract service class. Instead, 
the cited col. 14 mentions a logical separation of the functions of a GUI application, not service 
class implementations of a same abstract service class from different vendors as claimed. 

The cited col. 15 discusses different classes used to implement a user interface. For 
instance, an ActWfView class receives the menu and toolbar commands from the views and 
passes them to a window. A Map View class has a painter and controller components, where the 
controller component contains the menu, toolbar, mouse and keyboard interpreters. This class 
has methods to receive input from the users. The cited col. 15 further discusses various methods 
for a user interface, such as mouse methods, shapes, painting components to display images and 
areas. Further, the view classes get information from the model class, where the main interface 
for the model classes is a series of functions to manage attributes of the class. 
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Nowhere does the cited col. 15 anywhere teach, suggest or mention providing service 
class implementations of a same abstract service class from different vendors as claimed. The 
cited col. 15 discusses classes and methods for a user interface. There is no teaching or mention 
in the cited col. 15 of service class implementations from a same abstract service class provided 
by different vendors. Instead, the cited col. 15 discusses classes and methods to implement a 
user interface. 

Thus, the cited sections of Flores are devoid of any teaching or suggestion of the claim 
requirement of service class implementations of service engines from different service vendors 
providing an implementation of a same abstract service class. Instead, the cited Flores discuses 
workflows and an MVC framework for GUI applications. 

In the Response to Arguments, the Examiner did not address the above noted 
shortcomings of Flores, and just stated that these cited sections of Flores disclose the claim 
requirement concerning service class implementations from different service vendors using a 
same abstract service class. (Final Office Action, pgs.7-8) 

In the Response to Arguments, the Examiner further found that because Flores mentions 
that the module utilized a set of workflow rules, it is inherent that each service class includes 
methods from a parent or abstract class specifying method and objects in order for workflows to 
function properly as linked together. (Final Office Action, pg. 9) Although the cited Flores 
discusses different classes and method to implement a user interface, there is no mention, hint or 
suggestion in the cited Flores of different vendors implementing a same abstract service class to 
provide implementations of their vendor specific service engines. Further, although the cited 
Flores discusses a network of workflows linked together that represent a recurrent process in an 
organization, the Examiner has not cited any part of Flores that teaches or suggests that these 
workflows are from different vendors providing different implementations of a same abstract 
service class. 

For all the above mentioned reasons, Applicants submit that the cited Flores does not 
teach or suggest the claim requirements concerning the provided service class implementations. 

The Examiner cited the Abstract and col. 7, line 41 to col. 8, line 10 of Putzolu as 
teaching the claim requirement that each service class implementation provides an 
implementation of methods and objects from a same abstract service class. (Final Office Action, 
pg. 2) Applicants traverse on the grounds that the cited art does not teach the specific claimed 
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combination of service class implementations of a same abstract service class from different 
vendors as claimed. 

The cited cols. 7-8 mention providing an interface to agents including services. Services 
are Java classes instantiated as objects that have methods that accept inputs from agents and 
allow agents to access resources. Each resource on a network is accessible by agents via a 
service, such as the hard disk drive on each device is accessible by a disk service type. 

Although the cited cols. 7-8 mention service classes that allow agents to access resources, 
nowhere do the cited cols. 7-8 teach or suggest providing service class implementations of a 
same abstract service class from different vendors as claimed. In fact, cols. 7-8 teach away from 
this requirement because the cited cols. 7-8 mention that "[different types of services provide 
access to underlying resources in a different manner and interface with agents in a different 
manner" and that "the actual service class used by an agent to access a service type on each 
device may be different". Thus, cols. 7-8 do not teach service class implementations of methods 
and objects from a same abstract service class from different vendors. Instead, the cited cols. 7-8 
mention how services for different resources use different types of services and service classes, 
not implementations of the same abstract service class as claimed. 

The cited Abstract discusses allowing agents to function on devices having resources and 
that agents may move from an environment on one device to an environment on another device. 
Nowhere does the cited Abstract teach or suggest providing service class implementations of a 
same abstract service class as well as implementations from different vendors as claimed. 

Accordingly, Applicants submit that claims 1,17, and 33 are patentable over the cited art 
because the cited combination does not teach or suggest all the claim requirements. 

Claims 2-10, 13, 15, 18-26, 31, 34-42, and 47 are patentable over the cited art because 
they depend from one of claims 1, 17, and 33, which are patentable over the cited art for the 
reasons discussed above. Moreover, the below discussed dependent claims provide additional 
grounds of patentability over the cited art for the reasons discussed. 

Claims 3, 19, and 35 depend from claims 1, 17, and 33 and further require that the service 
engines include workflow products from different vendors, wherein the workflow products 
comprise computer programs enabling implementation of a computer implemented workflow 
defining a series of processes to be performed by users at computers with respect to a computer 
implemented work item. 
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The Examiner cited all col. 5, lines 54-59, col. 6, lines 12-24 and cols. 16, 17, and 18 of 
Flores as teaching the additional requirements of these claims. (Final Office Action, p. 3) 
Applicants traverse. 

Although the cited col. 5 mentions a network of workflows linked together, nowhere does 
the cited col. 5 anywhere teach or suggest that these workflows are products from different 
vendors as claimed. 

The cited col. 6 discusses aspects of a workflow and also fails to anywhere teach or 
suggest workflow products from different vendors that provide implementations from a same 
abstract service class as claimed. 

The cited col. 16 discusses a model class that implements workflow application logic, 
that describes the business process and its components in terms of classes. The cited col. 16 
further discusses different classes and their attributes. The WfComponent class is an abstract 
class providing the base for all classes which represent components of a process. 

The cited col. 17 discusses various workflow classes. A WfAnchor class is an abstract 
class which provides the meaning for origin/target objects as Workflows and conditional links. 
The WfWorkflow is a class that models the logical concept of the workflow, including customer 
performer, etc. Col. 18 discusses additional workflow related classes. 

Although the cited cols. 16, 17, and 28 discuss classes that describe the business process, 
its component, and workflow concepts, there is no teaching or suggestion in the cited cols. 16, 
17, and 18 of service engines including workflow products from different vendors. 

Accordingly, the additional requirements of claims 3, 19, and 35 provide additional 
grounds of patentability over the cited art. 

Claims 4, 20, and 36 depend from claims 3, 19, and 35 and further require that the 
workflow service class implementations from different vendors each includes methods and 
objects from a same abstract workflow service class specifying methods and objects to include in 
all workflow service class implementations. 

The cited col. 15 mentions that every view class has its model class equivalent where data 
is stored and that the main interface for the model classes is a series of functions to manage the 
attributes of the class. 

Although the cited col. 15 discusses functions used in a model class, nowhere does this 
cited col. 15 anywhere teach or suggest the claim requirement of workflow service class 
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implementations from different vendors including methods and objects from a same abstract 
workflow service class specifying methods and objects to include in all workflow service class 
implementations. 

The Examiner cited col. 15, lines 58-63, col. 19, lines 51-67 and col. 20, lines 1-67 of 
Flores as teaching the additional requirements of these claims. (Final Office Action, pg. 4) 
Applicants traverse. 

The cited col. 19 mentions that the Model utilizes workflow rules determined by the 
workflow structure, such as the number of phases, roles, workflow acts, cycle times, positions in 
the phase line where a link can be drawn, etc. Nowhere does this cited col. 19 anywhere teach 
or suggest the claim requirement of workflow service class implementations from different 
vendors including methods and objects from a same abstract workflow service class specifying 
methods and objects to include in all workflow service class implementations. 

The cited col. 20 mentions that an I/O module stores the model classes in map files. The 
view classes implement the user interface components to draw the model classes on the display. 
The cited col. 20 discusses view classes to display a map and draw the workflow symbols on the 
map, and classes to print the workflow symbols, and a shape class to derive the shapes to be 
drawn on the map. 

Although the cited cols. 15,19 and 20 discuss classes for a workflow and classes to view 
and draw symbols for a workflow, there is still no teaching, suggestion or mention of the claim 
requirement of workflow service class implementations from different vendors including 
methods and objects from a same abstract workflow service class. 

Accordingly, the additional requirements of claims 4, 20, and 36 provide additional 
grounds of patentability over the cited art. 

Applicants further submit that the additional requirements of other of the dependent 
claims in combination with the base claims provide further grounds of distinction over the cited 
art. 

2. Claims 1 1. 12. 14, 16, 27, 28, 30, 32, 43, 44, 46, and 48 are Patentable Over the Cited Art 
The Examiner rejected claims 11,12, 14, 16, 27, 28, 30, 32, 43, 44, 46, and 48 as obvious 
(35 U.S.C. § 103(a)) over Putzolu in view of Flores and further in view of Wollrath (U.S. Patent 
No. 6,487,607). Applicants traverse. 
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Applicants submit that the cited claims 11,12, 14, 16, 27, 28, 30, 32, 43, 44, 46, and 48 
are patentable over the cited art because they depend from one of claims 1, 17, and 33, which are 
patentable over the cited art for the reasons discussed above. Moreover, the additional 
requirements of these claims in combination with the base claims provide further grounds of 
distinction over the cited art. 

3. Added claims 49-50 are Patentable Over the Cited Art 

Added claims 49, 50, and 51 depend from claims 11, 19, and 27 and further require 
receiving, at the client system, a construct method to construct a client side service object to 
access the service engine; constructing the client side service object in response to the construct 
method; communicating the construct method to the server to cause the server to construct a 
server side service object; and issuing method calls from client applications in the client system 
to access information from the service engine using the constructed client-side and server side 
service objects. 

The additional requirements of these claims are disclosed on at least para. [0068]-[0069] 
and FIG. 9 of the Specification. 

Applicants submit that these claims are patentable over the cited art because the base 
claims from which they depend are patentable over the cited art for the reasons discussed above 
and because the additional requirements of these claims in combination with the base claims 
provide further grounds of patentability over the cited art. 

Conclusion 

For all the above reasons, Applicants submit that the pending claims 1-51 are patentable 
over the art of record. Applicants submit herewith the fee for the added claims. Nonetheless, 
should any additional fees be required, please charge Deposit Account No. 09-0460. 
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The attorney of record invites the Examiner to contact him at (310) 553-7977 if the 
Examiner believes such contact would advance the prosecution of the case. 



Please direct all correspondences to: 
David Victor 

Konrad Raynes & Victor, LLP 
315 South Beverly Drive, Ste. 210 
Beverly Hills, CA 90212 
Tel: 310-553-7977 
Fax:310-556-7984 



Dated: September 25, 2006 



By: /David Victor/ 

David W. Victor 
Registration No. 39,867 
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